Requirements management in general is concerned with the control of system requirements that are allocated to software to resolve issues before they are incorporated into the software project. It aims to accurately adjust plans and cost estimates as the requirements change, and to prioritize requirements according to their importance and their contribution to the final value of the product. There is very good reason to significantly improve the maturity of these processes. According to the Standish Research Group (“What are your requirements?” http://www.standishgroup.com/, 2002), the three leading causes of quality and delivery problems in software projects are related to requirements management issues: Lack of adequate user input, incomplete requirements and specifications, and changing requirements specifications.
A software release is a collection of new and/or changed features or requirements that form a new product. Release planning for incremental software development assigns features to releases such that most important technical, resource, risk and budget constraints are met. Without good release planning ‘critical’ features are jammed into the release late in the cycle without removing features or adjusting dates. This might result in unsatisfied customers, time and budget overruns, and a loss in market share, as indicated by Penny D., “An Estimation-Based Management Framework for Enhancive Maintenance in Commercial Software Products”, in Proc. International Conference on Software Maintenance, 2002. “Developing and releasing small increments of requirements, in order for customers to give feedback early, is a good way of finding out exactly what customers want, while assigning a low development effort” as stated in Carlshamre, P., “Release Planning in Market-Driven Software Product Development: Provoking an Understanding”. In: Requirements Engineering 7, pp 139-151, 2002.
There is a growing recognition that features act as an important organizing concept within the problem domain and as a communication mechanism between users and developers. They provide an efficient way to manage the complexity and size of requirements.
The concept of a feature is applicable and important for any software development paradigm. However, it is especially important for any type of incremental product development. Features are the “selling units” provided to the customer. Incremental development has many advantages over the traditional waterfall approach. First, prioritization of features ensures that the most important features are delivered first. This implies that benefits of the new system are realized earlier. Consequently, less important features are left until later and so, if the time or budget is not sufficient, the least important features are the ones most likely to be omitted. Second, customers receive an early version of the system and so are more likely to support the system and to provide feedback on it. Third, the schedule and cost for each delivery stage are easier to estimate due to smaller system size. This facilitates project management and control. Fourth, user feedback can be obtained at each stage and plans can be adjusted accordingly. Fifth, an incremental approach is sensitive to changes or additions to features.
Agile methods as described in Cockburn, A., “Agile Software Development”, Pearson Education, 2002, have capitalized on the above advantages. In Extreme Programming (Beck, K. “Extreme Programming Explained”, Addison Wesley, 2001), a software product is first described in terms of ‘user stories’. These are informal descriptions of user requirements. In the planning process, these stories are prioritized using the perceived value to the user and assigned to releases. Based on estimates of how long each story in an increment will take to implement, an iteration plan is developed for delivering that release. Each increment (or release) is a completed product of use to the customer. At any time, new stories may be added and incorporated into future releases.
The requirements engineering process is a decision-rich problem solving activity (Aurum, A., Wohlin, C., “The Fundamental Nature of Requirement Engineering Activities as a Decision-Making Process”, Information and Software Technology 2003, Vol. 45 (2003), No. 14, pp. 945-954.) One of the most prominent issues involved in incremental software development is to decide upon the most promising software release plans while taking into account diverse qualitative and quantitative project data. This is called release planning. The input for the release planning process is a set of features that are evolving due to changing user requirements and better problem understanding. Despite the obvious importance of the problem in current incremental and evolutionary development, it is poorly studied in the literature.
Release planning considers stakeholder priorities and different types of constraints. The output of the release planning process is a set of candidate assignments of features to increments. They are supposed to represent a good balance between stakeholder priorities and the shortage of resources. In each increment, all the features are executed following one of the existing software development paradigms including analysis, system design, detailed design, implementation, component testing, system testing, and user testing. All the features are inputted into this process. As a result, a usable (release) product is provided. This fundamental procedure of planning and development of releases is illustrated in FIG. 2. Release planning assigns features to release options 1 (dark grey), 2 (grey) or 3 (white). Within each release development cycles, all features are passing the stages of a software development cycle. This cycle includes verification and validation activities at the different product stages (requirement, system design, component design, code). At the end of this process, a verified and validated release product is delivered. This principle can be easily extended to planning of more than two releases ahead.
Without any technological, resource, risk and financial constraints, all the features could be implemented in one release. However, the existence of all the constraints implies the questions: what comes first and why? The goal of release planning is to account for all these factors and to come up with suggestions for the most satisfactory release plans. There are two fundamental types of release planning problems: (i) release planning with fixed and pre-determined time interval for implementation, and (ii) planning with flexible intervals. In the second problem, you also decide about the length of the interval to implement all the assigned features. This type of planning is also called ‘Open scope release planning’.
Software Release Planning adds to two well-established disciplines of (incremental) software development: (i) requirements management, especially requirements prioritization, and (ii) software project planning and management. Defining the commonalities and differences between them helps to better understand release planning. Requirements management is the process of identifying, documenting, communicating, tracking and managing project requirements as well as changes to those requirements. As requirements are changing, or are becoming better understood, or new requirements are arising, requirements management is an ongoing activity.
Requirements prioritization is trying to determine the different degrees of priority. The problem of still delivering a large amount of features that are never used, and vice versa, not delivering those that are required, has (among others) to do with a lack of understanding and prioritization. As a feature has different relevant attributes (such as its functionality, inherent risk, effort of implementation) that contribute to the final judgement, requirements prioritization is a multi-attributive decision problem. Practically, most emphasis is on the provided functionality of the feature. Specifically, requirements prioritization is also a multi-person (multi-criteria) decision problem, as the prioritization is typically performed in a team-session. There is no clear description on how the different and conflicting opinions are actually negotiated.
Release planning may be characterized as “wicked”. That means that the objective is “to maximize the benefit”, but it is difficult to give a measurable definition of “benefit”. Wicked problems have no stopping rule in its solution procedure. The underlying model is “evolving”: the more we study the problem, the more sophisticated the model becomes. Wicked problems have better or worse solutions, but no optimal one. Although we are approximating the reality, implicit and tacit judgment and knowledge will always influence the actual decisions. As a consequence of all these difficulties, we propose to rely on the synergy between computational strength and the experience and intelligence of the human decision maker as proposed by the paradigm of software engineering decision support.
Release planning is a very complex problem including different stakeholder perspectives, competing objectives and different types of constraints. Release planning is impacted by a huge number of inherent constraints. Most of the features are not independent from each other. Typically, there are precedence and/or coupling constraints between them that have to be satisfied. Furthermore, effort, resource, and budget constraints have to be fulfilled for each release. The overall goal is to find a relatively small set of “most promising” release plans such that the overall value and the degree of satisfaction of all the different stakeholders are maximized. The topic of investigation is uncertain and incomplete in its nature:                Features are not well specified and understood: There is usually no formal way to describe the features and requirements. Non-standard format of feature specification often leads to incomplete descriptions and makes it harder for stakeholders to properly understand and evaluate features and requirements.        Stakeholder involvement: In most cases, stakeholders are not sufficiently involved in the planning process. This is especially true for the final users of the system. Often, stakeholders are unsure why certain plans were suggested. In the case of conflicting priorities, knowing the details of compromises and why they were made would be useful. All these issues add to the complexity of the problem at hand and if not handled properly, they create a huge possibility for project failures        Change of features and requirements and other problem parameters: Features and requirements always change as the project progresses. If a large number of features increase the complexity of the project, their dynamic nature can pose another challenge. Other parameters such as the number of stakeholders, their priorities, etc., also change with time—adding to the overall complexity.        Size and complexity of the problem: Size and complexity are major problems for project managers when choosing release plans—some projects may have hundreds or even thousands of features. The size and complexity of the problem (known to be NP-complete), and the tendency for not involving all of the contributing factors, makes the problem prohibitively difficult to solve by individual judgment or trial and error type methods.        Uncertainty of data: Meaningful data for release planning are hard to gather and/or uncertain. Specifically, estimates of the available effort, dependencies of features, and definition of preferences from the perspective of involved stakeholders are difficult to gauge.        Availability of data: Different types of information are necessary for actually conducting release planning. Some of the required data are available from other information sources within the organization. Ideally, release planning is incorporated into existing Enterprise Resource Planning or other organizational information systems.        Constraints: A project manager has to consider various constraints while allocating the features and requirements to various releases. Most frequently, these constraints are related to resources, schedule, budget or effort.        Unclear objectives: ‘Good’ release plans are hard to define at the beginning. There are competing objectives such as cost and benefit, time and quality, and it is unclear which target level should be achieved.        Efficiency and effectiveness of release planning: Release plans have to be updated frequently due to changing project and organizational parameters. Ad hoc methods help determine solutions but are far behind objective demands.        Tool support: Currently, only general-purpose tools for features management are available. Most of them do not focus on the characteristics of release planning.Solution Methods and Techniques        
Prioritization in general answers the questions to classify objects according to their importance. This does not necessarily imply a complete ranking of all objects, but at least an assignment to classes like ‘Extremely important’, ‘important’, or ‘of moderate importance’. Different scales are applicable according to the underlying degree of knowledge you have about the objects. Prioritization always assumes one or a collection of criteria to actually perform the process.
In Karlsson, J., Wohlin, C and Regnell, B., “An Evaluation of Methods for Prioritising Software Requirements”, Information and Software Technology 39 (1998), pp 939-947, a requirements prioritization session is characterized by three consecutive stages:                Preparation: Structuring of the requirements according to the principles of the method to be applied. Provide all information available.        Execution: Agreement on criteria between all team members. Decision makers do the actual prioritization with all the information available. In general, this step needs negotiation and re-iteration.        Presentation: Final presentation of results to those involved in the process.        
There are a number of existing approaches to requirements prioritization. The most important ones have been studied and compared in Karlsson et al. (referenced above). Among them are the analytic hierarchy process (AHP), binary search tree creation, greedy-type algorithms and other sorting-based methods. As a result of their evaluation, they have found out that AHP is the most promising approach. Most of those algorithms need O(n2) comparisons between the n requirements. This effort required soon becomes prohibitive for larger number of requirements. In addition to that, none of the mentioned algorithms takes into account different stakeholder perspectives.
The Analytic Hierarchy Process (AHP) is a systematic approach to elicit implicit preferences between different involved attributes, as discussed in Saaty T. L.: The Analytic Hierarchy Process, Wiley, New York, 1980. For the purpose of this investigation, AHP is applied to determine the importance of the various stakeholders from a business perspective. In addition, it is used to prioritize the different classes of requirements from the perspective of each stakeholder. The two preference schemata are combined to judge rank the importance of the different classes of requirements for the final business value of the software product. AHP assumes that the problem under investigation can be structured as an attributive hierarchy with at least three levels. On At the first level, the overall goal is described. The second level is to describes the different competing criteria that refining the overall goal of level 1. Finally, the third level is devoted to be used for the selection from competing alternatives.
At each level of the hierarchy, a decision-maker performs a pair-wise comparison of attributes assessing their contributions to each of the higher level nodes to which they are linked. This pair-wise comparison involves preference ratios (for actions) or importance ratios (for criteria). The expert assigns an importance number that represents the importance of a term ti with respect to another term tj to describe the domain.
Priority decisions become more complicated in the presence of stakeholders having different relative importance and different preferences. It becomes very hard in the presence of constraints about sequencing and coupling of requirements in various increments, and taking into account resource allocation for implementation of requirements. None of the methods mentioned above can be applied under these circumstances.
Amongst the informal approaches claiming to handle release-planning, one of the most well known ones is ‘planning games’ as used in agile development. The goal of this approach is to deliver maximum value to the customer in least time possible. In half to one day long sessions, customers write story cards describing the features they want, while developers assign their estimates to those features. The customers then choose the most promising story cards for the next increment by either setting a release date and adding the cards until the estimated total matches the release date, or selecting the highest value cards first and setting the release date based on the estimates given on them.
This simplistic approach works well in smaller projects. However, as the size and the complexity of the projects increases, the decisions involved in release planning become very complex. Various factors come into play, such as the presence of stakeholders having different relative importance and different preferences, the presence of constraints about sequencing and coupling of requirements in various increments, and the need to take into account resource allocation issues for implementing the requirements. Considering problems involving several hundreds of requirements and large number of widely scattered stakeholders, it becomes very hard to find appropriate solutions without intelligent support tools. The goal of such support is to account for all these factors in order to come up with a set of most promising release plans.